Speed up deck list by rendering it with the backend #11599

dae · 2022-06-11T09:13:35Z

This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code.

Depends on the following PRs in this repo:

#11579
#11581

And on a new backend release from David, after merging

ankidroid/anki#1

Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method.

Currently limited to V1 due to changes in 2.1.41

This requires david-allison/anki#2 to be merged into a new AnkiDroid backend release before this can be used.

The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future.

dae · 2022-06-11T09:15:49Z

Once AnkiDroid has moved to V16, the old Java code can be cut: 5fa2b05

mikehardy · 2022-06-11T16:38:04Z

Dependent work to integrate the required change in Anki-Android-Backend tracked here ankidroid/Anki-Android-Backend#200

mikehardy · 2022-06-11T17:48:38Z

@dae meta comment - thanks a bunch for all the little fixes in here by the way going to do my best to unblock / merge / release all this stuff so any of your time spent is productive as we can obviously really use the extra set of hands in the area

This moves closer to unblocking ankidroid#11599

This moves closer to unblocking #11599

mikehardy · 2022-06-12T03:04:01Z

This should be rebased, I managed to bull through cherry-picking the patch in a merge-able spot, and figuring out how to publish the backend, and integrated it here #11605 - so now depends on the other PRs but not any other deep infra

does it really depend on those other two PRs? I'm not sure based on my read of those how this one would depend but maybe I'm being dense, seems they are orthogonal in intent? Or does this actually depend on V16 somehow (which seems more than those other 2 PRs do...)

dae · 2022-06-12T03:08:15Z

If #11581 is not merged, I think the build will fail as the abstract method is not implemented in the Java backend. The tests are not a hard requirement, but having 0 failing tests makes it easier to see that this PR hasn't introduced failing ones :-)

mikehardy · 2022-06-12T13:11:21Z

Ok - I understand the dependency now I think, obvious in hind sight. 2 paths then:

1- low effort / longer time path: leave as is + blocked by dependency on java backend drop PR while I get acrarium (new crash report system) setup and we get a sample to base dropping the backend on just to make sure, probably a week, but deadlines are open source poison so could be who knows
2- untangle the two PRs by altering this one so it is before dropping the backend

I think 1 is fine, I'm not pushing for 2 just saying how it will go since this will sit for a bit then

optimizing for fewer comments vs having this on the right thread I'll say I'm still confused on the V16 test PR, as I had literally zero success with it in "testing v16 mode", I just don't know how you got that one to pass.

dae · 2022-06-12T14:45:52Z

No big rush on my end - I've fallen down the rabbit hole of looking into what's involved with updating AnkiDroidBackend to the latest desktop code, which is why I haven't had a chance to try repro the issue you reported yet.

If it's easy, could I trouble you to get Kotlin working on the backend repo? I tried following some instructions online to add the deps/classpath to the build.gradle files, but was still seeing missing symbol errors when I tried converting one of the files to kotlin (from the java files that were trying to access it).

dae · 2022-06-13T05:15:13Z

Nevermind, I think I'm close to getting it working now.

mikehardy · 2022-06-13T07:11:57Z

I just got our crash report database up so we're back to 💯 after the server compromise, so I can circle back around and focus more on this again in the next couple days myself

This moves closer to unblocking ankidroid#11599

@Arthur-Milchior

This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599

dae · 2022-06-20T09:32:13Z

I've merged this into #11644

@Arthur-Milchior

This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599

@Arthur-Milchior

This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599

@Arthur-Milchior

This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599

@Arthur-Milchior

This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599

@Arthur-Milchior

This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599

@Arthur-Milchior

This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599

@Arthur-Milchior

This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599

@Arthur-Milchior

Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599

@Arthur-Milchior

Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599

@Arthur-Milchior

Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599

@Arthur-Milchior

This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599

@Arthur-Milchior

Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599

@Arthur-Milchior

Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599

@Arthur-Milchior

Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599

@Arthur-Milchior

Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from #11599

This moves closer to unblocking ankidroid#11599

@Arthur-Milchior

Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method. Speed up deck list by rendering it with the backend This delegates to the backend to render the deck tree, instead of calculating it in Java. On @Arthur-Milchior's large collection with the daily limits turned up, the speed difference in an x86_64 sim is dramatic: 2.4s with the old Java code, and 70ms with the new Rust code. - Make deckDueList() private; switch callers to use deckDueTree() The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future. Squashed from ankidroid#11599

dae added 5 commits June 11, 2022 19:09

Don't store collection reference in DeckTreeNode

d2be0ea

Pass it in to processChildren() instead, which is cleaner, and will work better with the move to a backend method.

Use backend to generate deck list for V1 scheduler

545ae1b

Currently limited to V1 due to changes in 2.1.41

Enable backend deck list code for v2 scheduler

1545369

This requires david-allison/anki#2 to be merged into a new AnkiDroid backend release before this can be used.

Make deckDueList() private; switch callers to use deckDueTree()

00bcc9d

The backend only provides a deckDueTree(), and switching the calls to deckDueList() now will make migration easier in the future.

Use backend for quickDeckDueTree()

7a6a92c

dae force-pushed the deck-tree branch from 2364212 to 7a6a92c Compare June 11, 2022 09:14

mikehardy mentioned this pull request Jun 11, 2022

fix(anki): update ref to include https://github.com/ankidroid/anki/pull/1 ankidroid/Anki-Android-Backend#200

Merged

This was referenced Jun 11, 2022

Move sonatype groupId to org.ankidroid ankidroid/Anki-Android-Backend#33

Open

release: 0.1.11 ankidroid/Anki-Android-Backend#201

Merged

mikehardy added a commit to mikehardy/Anki-Android that referenced this pull request Jun 12, 2022

build(deps): use anki-android-backend:1.1.11

c307ee5

This moves closer to unblocking ankidroid#11599

mikehardy mentioned this pull request Jun 12, 2022

build(deps): use anki-android-backend:1.1.11 #11605

Merged

7 tasks

mikehardy added the Blocked by dependency Currently blocked by some other dependent / related change label Jun 12, 2022

mikehardy added a commit that referenced this pull request Jun 12, 2022

build(deps): use anki-android-backend:1.1.11

32caa8e

This moves closer to unblocking #11599

thedroiddiv pushed a commit to thedroiddiv/Anki-Android that referenced this pull request Jun 14, 2022

build(deps): use anki-android-backend:1.1.11

e6a451c

This moves closer to unblocking ankidroid#11599

dae closed this Jun 20, 2022

dorrin-sot pushed a commit to dorrin-sot/Anki-Android that referenced this pull request Jul 14, 2022

build(deps): use anki-android-backend:1.1.11

96aaaf0

This moves closer to unblocking ankidroid#11599

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Speed up deck list by rendering it with the backend #11599

Speed up deck list by rendering it with the backend #11599

dae commented Jun 11, 2022 •

edited by mikehardy

Loading

dae commented Jun 11, 2022

mikehardy commented Jun 11, 2022

mikehardy commented Jun 11, 2022

mikehardy commented Jun 12, 2022

dae commented Jun 12, 2022

mikehardy commented Jun 12, 2022

dae commented Jun 12, 2022

dae commented Jun 13, 2022

mikehardy commented Jun 13, 2022

dae commented Jun 20, 2022

Speed up deck list by rendering it with the backend #11599

Speed up deck list by rendering it with the backend #11599

Conversation

dae commented Jun 11, 2022 • edited by mikehardy Loading

dae commented Jun 11, 2022

mikehardy commented Jun 11, 2022

mikehardy commented Jun 11, 2022

mikehardy commented Jun 12, 2022

dae commented Jun 12, 2022

mikehardy commented Jun 12, 2022

dae commented Jun 12, 2022

dae commented Jun 13, 2022

mikehardy commented Jun 13, 2022

dae commented Jun 20, 2022

dae commented Jun 11, 2022 •

edited by mikehardy

Loading